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REMARKS 

Claims 1-7 are currently pending in the application. Claim 2 has been rewritten in 
independent form by addition of language of Claim 1 from which Claim 2 originally 
depended. This amendment, therefore, doe not present any new issues and is proper for 
entry and consideration at this time as it either places claims 2-6 in prima facie condition 
for allowance, or places the application in better condition for review on appeal. 

The Claimed Invention 
The claimed invention involves a system and process for managing business, 
technical and operational data using a single interface in a shared space environment over 
the Internet. 

As discussed previously, a supplier portal creates a central repository for 
registration process, information, company information, and user information, making 
this information available to all applications that open into the supplier portal. A 
userid/password 102 is obtained from a supplier (guest) coordinator 101 and supplied to a 
business representative 103. An application coordinator provides information to a portal 
administrator at 104. This information includes the company name, application, and 
supplier coordinator name, userid, email, etc. A determination is made in decision block 
105 as to whether the supplier is registered. If the supplier is not registered, then a 
company profile is created in function block 106. If the supplier is registered, then a 
further determination is made in decision block 107 as to whether the application is 
registered. If the application is not registered, then a company and its mapping is created 
in function block 108 and, in function block 109, the supplier coordinator is registered 
and authorized to use the application. If the application is registered as determined in 
decision block 107, then a further determination is made in decision block 1 10 as to 
whether the application is mapped to the supplier and supplier coordinator. If the 
application is not mapped to the supplier and supplier coordinator, the supplier 
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coordinator mapping to the application is crated in function block 111. Finally, an email 
note is sent to the supplier coordinator application administrator in function block 112. 

In the last office action, the approval cycle was not fully addressed. An approval 
cycle is used to determine how to route a request for processing for granting access to an 
application under a supplier portal. (Claim 1, line 16; Claim 2, lines 17, 27; Claim 3, 
line 2; Claim 4, line 2; and Claim 7, line 14) An approval cycle consists of five major 
components: (i) an application ID for which a request is submitted, (ii) the function code 
of the request or the type of the request, that is, first time enrollment request, modification 
request, etc., (iii) the role level of the user ID that submits the request, that as a brand new 
user, a regular registered user, a company focal point, etc., (iv) the cycle step number of 
the approval cycle, that is, step 1 or 2 or 3, etc. (as specified in claim 2, approval cycle 
steps could be from 1 to n), and (v) the role level that is required to process the request 
that is to either approve or reject the request or to put the request on hold, etc. 

Once a request is submitted in the supplier portal, all defined approval cycles are 
consulted to identify the exact approval cycle applicable for the request, and then based 
on the approver role level defined in that approval cycle, portal data store is consulted to 
identify the approvers with that role level for the application in question and notified via 
email that a request is pending their approval These approvers when logged on to 
supplier portal are presented a link to these pending requests where they can process each 
individual requests. 

For example, in one embodiment approval cycles may be customizable for each 
application - Application A may decide to setup a three-step approval cycle such that at 
the first step of the approval process, someone from IBM would need to give the initial 
approval and then at the next step, a company focal point from the user's company, e.g., 
Company B, would need to give their approval with the third and final approval from 
another IBM administrator. Whereas, Application B may decide to define a single step 
approval cycle such that when a request is submitted by the users of Company B, only an 
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approval from the focal point of the Company B is required. This embodiment is covered 
in claim 3 of the application. 

As another example, an approval cycle may be definable for a section of an 
application. Application C may define its approval cycle such that when a request to 
access Application C is submitted, with all requests routed to a single set of approvers. 
But it also can define its approval cycles based on certain criteria, like, geography, line of 
business, etc. For example, Application C may define that when a request for 
Application C is submitted by users from EMEA, those requests would need to go 
through a three-step approval process, as opposed to going through a process of only two 
steps if the requests were submitted by NA users (geography based). Obviously, 
approvers could/would be different for the requests for the users from EMEA than those 
from NA. This embodiment is covered in claim 4 of the application. 

As a final example, application specific registration fields may be unique to an 
application. Thus, Application D may require that users requesting access to this 
application need to provide answers to three specific questions in order to consider their 
requests, for example, what language they would like to see the contents in the 
application, what role they expect to perform in the application, etc. Application E on the 
other hand may require to ask five totally different questions for users requesting access 
to this application. Any or all of these questions can be defined as mandatory or optional 
at the discretion of the Application D or Application E. This embodiment is covered in 
claim 5 of the application. 

Rejection of Claims 1-7 
Claims 1-7 have been rejected under 35 U.S.C. § 103(a) as obvious in view of 
U.S. Patent No. 6,606,606 to Starr in view of U.S. Patent No. 6,61 1,275 to Zey et al. 
This rejection essentially repeats verbatim the previous rejection of Claims 1-7 in the 
previous office action. As a result, Applicant's response to the previous office action is 
incorporated herein by reference as if fully restated herein. 
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In responding to Applicants' arguments in response to the previous office action, 
the Examiner has ignored Applicant's argument that a combination of Starr with Zey et 
al. is not obvious while rejecting Applicant's argument that the use of email by Zey et al. 
does not suggest the use of email in the claimed invention (so that the combination, even 
if obvious, would not result in the claimed invention). (Office Action at 6-7) 

Applicants traverse as discussed below, it being understood that the steps of 
determining whether applications have been authorized, accessing information from the 
GR data store to automatically build a customized home page, and determining whehter 
approval is needed are not obvious within the context of the recited process and system of 
claims 1, 2 and 7, over any combination of Starr and Zey, and it further being understood 
that the features of claims 2-5 are separately not obvious over any combination of Starr 
and Zey as features required in these claims are not present in either the Starr or Zey 
references. 

Claims 1 and 7 

Independent Claims 1 and 7, which have been rejected as obvious in view of Starr 
and Zey et al., claim a supplier portal which is patentably distinct from what is taught by 
Starr and/or Zey et al. Claims 1 and 7 enable the management of business, technical and 
operational data using a single interface in a shared space environment over the Internet 
by: (a) providing a supplier portal (Claim 1, lines 4-6, and Claim 7, lines 4-5); 
(b) determining whether a guest is a registered user (Claim 1, lines 7-10, and Claim 7, 
lines 6-10); (c) storing guest information (Claim 1, lines 11-12, and Claim 7, lines 11-14); 
(d) determining whether applications have been authorized for a registered guest 
(Claim 1, lines 13-16, and Claim 7, lines 15-17); (e) accessing information to build a 
customized home page for the guest (Claim 1, lines 17-19, and Claim 7, lines 18-20); 
(f) determining whether approval is needed for a requested application and, if so, sending 
by email a request for approval to the application administrator and receiving a response 
from the application administrator (Claim 1, lines 20-22, and Claim 7, lines 21-23); and 
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(g) storing links to all applications for which the guest is approved (Claim 1, lines 23-25, 
and Claim 7, lines 24-26). 

With regard to the step of determining whether applications have been authorized 
for a registered guest (Claim 1, lines 13-16, and Claim 7, lines 15-17), this feature is not 
suggested by either Starr and/or Zey et al. In the practice of the invention, once users are 
logged onto a "supplier portal," they are presented with a "new user enrollment" option if 
they are not enrolled to any application; however, they are given options to enroll for 
other applications if they already have access to at least one application. All such 
enrollment data is stored in the data store during the approval process. The Examiner has 
incorrectly relied on Starr as showing or suggesting this feature in column 10, lines 30- 
47; however, careful review of that section of Starr reveals that it is focused on permitting 
the user to engage in a number of financial transactions involving his account. This not 
the same as permitting a user to register for the use of different restricted applications, 
and having the data stored in a portal common registration. The invention allows data 
required for registering to have access to one application to be used for registration to 
have access to another application. In sharp contrast, Starr is merely directed to allowing 
you, once you are registered, to engage in a number of different transactions using the 
same application. 

With regard to the step of accessing information to build a customized home page 
for the guest (Claim 1, lines 17-19, and Claim 7, lines 18-20), this feature is likewise not 
suggested by either Starr and/or Zey et al. Each user's home page is dynamically built 
based on his or her current access level in the "supplier portal" displaying the applications 
the user has been granted access to, any pending access requests the user needs to process, 
and the functions the user is allowed to perform in the "supplier portal." These three 
components dynamically keep changing as the user's access changes. The Examiner has 
incorrectly relied on Starr as showing or suggesting this feature in column 10, line 47 to 
column 11, line 1 1 ; however, careful review of that section of Starr reveals that it is 
focused on the user having control of his financial transactions and information on 
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financial records. Once the user is registered in Starr, he can specify bill paying 
operations, he can download data or upload data for use in Quicken or another product, 
etc. But this passage of Starr is completely unrelated to building a modifiable and 
updatable page as the gues t's requests for access to applications get approved as required 
in claims 1 and 7. As noted above, the invention allows registration data to be used for 
gaining access to additional desired applications. The invention also provides a 
customized web page which tracks the applications which are authorized and to which the 
user is registered. In sharp contrast, the passage in Starr is merely related to having the 
user control his financial data and transactions, and is unrelated to registering the user to 
use different applications or tracking the applications to which he is registered in a 
customized web page. 

Finally, with regard to the step of determining whether approval is needed for a 
requested application and, if so, sending by email a request for approval to the application 
administrator and receiving a response from the application administrator (Claim 1, lines 
20-22, and Claim 7, lines 21-23), this feature is not suggested by Starr and/or Zey et al. 
Once a request for access to an application is submitted, the approver for that application 
is sent an email informing him or her that there is a request pending which requires his or 
her approval. The approver is then able either to approve or to reject the request, 
resulting in further emails being sent to the submitter of the requests. The Examiner has 
incorrectly read Zey et al. as suggesting the use of email according to Claims 1 and 7. 
Zey et al. teach generating an email to provide notice as to whether an approval has been 
denied or granted but do not teach do not teach using email to forward a request for 
approval to an approver, as in Claims 1 and 7. (Zey et al., column 8, lines 23-37, cited in 
the Office Action at 4) Furthermore, Zey et al. do not teach use of an email feature in 
connection requesting, granting, or denying approval to use "a requested application" 
(Claim 1, line 20; and Claim 7, line 21) but instead teach the use of email in connection 
with communicating or scheduling maintenance requests. Because Starr does not deal 
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with either email notification or granting access to different applications (note arguments 
above), combining Zey et al. with Starr would not provide these missing features. 

Claim 2 

The rejection of Claim 2 is traversed on the basis that Claim 2 has features not 
present in either Starr or Zey et al., which are not addressed by the Examiner in the Office 
Action. In addition to what is claimed by Claim 1, Claim 2 provides the step of: 

defining 1 to n level approval cycles a user must go through to get 
authorized to access an application; 

logging in by a registered guest by inputting the guest's 
usereid/password once for each session, as long as applications requested 
by the guest are in a same realm; and 

invoking by a logged in guest any of their approved applications by 
simply clicking the link to the desired application in the guest's customized 
home page. 

(Claim 2, lines 27-32). These features, which were not fully addressed by the Examiner 
in the office actions, and are not found in either Starr or Zey et al. There is no reason to 
conclude that features absent from both references would emerge from a combination of 
the two. The Examiner has incorrectly relied on passages in column 9, lines 20-30, 
column 8, lines 37-65, and column 8, lines 21-25 in Starr as being related to these 
features. However, careful review of these passages reveals that Starr is not related to an 
approval process for gaining access to a plurality of applications through a common 
portal. At no point does Starr discuss or suggest 1 to n level of approval cycles a user 
must go through to get authorized to access an application. As discussed above and in the 
application, in the context of a "supplier portal", an approval cycle is used to determine 
how to route a request for processing for granting access to an application. An approval 
cycle consists of 5 major components - i) an application ID for which a request is 
submitted, ii) the function code of the request or the type of the request, that is, first time 
enrollment request, modification request, etc., iii) the role level of the user ID that 
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submits the request, that as a brand new user, a regular registered user, a company focal 
point, etc., iv) the cycle step # of the approval cycle, that is, step 1 or 2 or 3, etc. (that is 
an approval cycle steps could be from 1 to n) and v) the role level that is required to 
process the request that is to either approve or reject the request or to put the request on 
hold, etc. Once a request is submitted in the Supplier Portal', all defined approval cycles 
are consulted to identify the exact approval cycle applicable for the request, and then 
based on the approver role level defined in that approval cycle, Portal data store is 
consulted to identify the approvers with that role level for the application in question and 
notified via e-mail that a request is pending their approval. In sharp contrast, Starr merely 
deals with logging on to an application for secure transactions, and is unrelated to an 
approval cycle in the context of a supplier portal. 

Claims 3-6 

The rejection of Claims 3-6 is traversed on the basis that Claims 3-6 should be 
allowed as dependent from allowable Claim 2. Claims 3-6 provide the following 
features: 

approval cycles are customizable for each application 
(Claim 3, line 2); 

approval cycles are defined for a section of an application, providing a 

finer level of access control 
(Claim 4, lines 2-3); 

application specific registration fields are defined so that a registration 

form, unique to an application, is displayed when a user requests access to 

an application 
(Claim 5, lines 2-4); and 

guests may bookmark applications for later access, further comprising the 

step of prompting by an application a guest to enter their userid/password 
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for authentication against data stored in the GR data store when the 
application is accessed using a bookmark. 
(Claim 6, lines 2-5) 

The features added by Claims 3-6 are features not present in either Starr or Zey et 
al. and are not addressed by the Examiner in the Office Action. There is no reason to 
conclude that feature absent from both Starr and Zey et al. would emerge from a 
combination of the two references. The Examiner has incorrectly relied on Starr as 
showing these features at column 9, lines 26-30 (this section merely deals with a login 
and no teaching or suggestion whatsoever concerning having customizable approval 
cycles as required in claim 3), column 9, lines 22-26 (this section merely deals with 
having login data stored in a database and has no teaching or suggestion whatsoever 
concerning having approval cycles defined for a section of an application as required in 
claim 4), and column 8, lines 37-51 (this section deals with having a user have different 
levels of access to information within an application, and is not related whatsoever to 
having application specific registration fields that are unique to an application being 
displayed on a registration form when a user requests access to an application (i.e., in this 
passage of Starr, the person's level of access is being determined-he is not being 
presented with application specific registration fields in a registration form). 

Conclusion 

In view of the foregoing, it is respectfully requested that Claims 1-7 be allowed 
and that the application be passed to issue. In the alternative, it is requested that this 
amendment be entered for purpose of appeal. 

Should the Examiner find the application to be other than in condition for 
allowance, the Examiner is requested to contact the undersigned at the local telephone 
number listed below to discuss any other changes deemed necessary in a telephonic or 
personal interview. 
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A provisional petition is hereby made for any extension of time necessary for the 
continued pendency during the life of this application. Please charge any fees for such 
provisional petition and any deficiencies in fees and credit any overpayment of fees to 
Deposit Account No. 09-0458 (IBM-Fishkill). 
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